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(54) Title: METHOD FOR ORGANIZING A DIGITAL DATABASE IN A TRACEABLE FORM 

(54) TItre : PROCBDE D ORGANISATION D UNE BASE DE DONNEES NUMERIQUES SOUS UNE FORME TRACABLE 

l^!^f"'''^ invention concerns a method for oiganizing a digital database in a traceable fonn, comprising steps which consist 
^ reo^^^\' """" H '^'''^ s.pp^lng or changiog a record of the main kise J^T^^^ 

^ leprodocing the main database. The invention is characterized in that the step of modi Wng the main database ind^^ 
5 - whichconsjsuin creating at least one digital recording comprisingatl^^ unique dirital identif^of^^^^^ 
B 3 atinbutes of the main database, a unique digital identifier of the slate of the mahTdatobL colS^^inn 

m " ^^"^ composing the catena of the original request and the identifier of the state concerned, and r«:oZtStS tS 

M ^\«>'«^P^.'«*\"« ^j^f <^riteria of the original request and to the state concerned, the method furtlTcoZiS^ 

If? ■ ^"'^ d'oiganisaiion d'une base de donnies num^riques sous one fonne Iracable comooitant Aane. A, 

O P""«P^' " dc la ba5c de don„6es principale. can«:t4ris« e« ce que I'^lape de nwd^SdL la tosT^ 

fiants num^nques uniques dcs enregistrements et des auributs concern^ de la base de donndw oriiUMde ™ idenriZ^i „!l«^^^ 
S '"'r * ""^^ '"""^^ correspondam 4 tadite modification ria^JS^^ 

S ^ir^^TTvZr^f^:' " e„«gi««men. dans u« base d'historisatl^merne compJe Su m^STane 

g toble. et cn ce qoe I etape de lecture portanl sur tout Hai final on anierieur de la base de donn&s princiDale cons^ste k tbc^ZiZ 
S onSKT' "'S'' ' 1'iden.ificateur unique de V^m vis^. . proc^er^neTn^^^ro t e ^ite 

O « r«! ^rTT^i" one lequete modifiee d'adressage de la base d'historisadon comp^^™«. lescritiies de la rco^tSne 
S I v^^^Zi^''' " - enn=gis.n.menu coa«spo«^m aux enters de la .eqSriZlte 

^ et nm ^Sl"**?"*"'^' r f ^ ""ivi des operations, des dep^dancc"^«5^. 

et I impact des changemenis. ainsi que la fusion de branches on I'lSvolution de la stractore des donn&s. «>««ies 
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La prgsente invention se rapporte au domaine de 
la gestion des donnfiee persistantes d'une entitS, par 
exemple une entreprise. En particulier, la prSsente 
invention se rapporte au suivi de ces donnSes persistantes 
dans une base de donnSes par 1 ' intermedia ire d'un SystSme 
de Gestion de Base de Donnfies, 11 est en effet difficile 
pour une entreprise de garantir le suivi du processus 
d' Evolution des donn^es persistantes stratggiques car ce 
suivi prSsente quelques obstacles objectifs : 

• Caractfire asynchrone et collaboratif du 
15 dSroulement du processtis 

• CaractSre tr«s exigeant du suivi pour constituer 
une rSelle garantie : la presence d'un maillon faible 
compromet d6f initivement la fiabilitfi de toute r^ponse 

Non disponibilitfi de solutions gSngriques de 
20 prise en charge de la tra^sabilit* dans les couches 
logicielles du mareh« a un niveau de granularity 
satisfaisant : OS. SGBD, langage de dSveloppement 

• Co<it trSs 61ev6 de rSeriture des applications 
existantes et coiit trSs 61ev6 de prise en compte eaqplicite 

25 de la tra?abillt6 par cheque application. 

L'art antSrieur connalt d6ja par la denande de 
brevet international WO 9935566 un procSdS d' identification 
et de suivi des Evolutions d'un ensemble de composants 
logiciels. Le proc6d6 propose par ce document de l'art 
ant^rieur permet de recenser des composants par leur nom et 
leur version. Cette classification au niveau fichier ne 
correspond pas au problSme de conserver des traces de 
donnSes de maniSre continue, c'est-a-dire S chaque 
modification desdites donnfies. En particulier, le proc6d6 
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propose ne convient pas pour tracer xine base de donnSes 
modifiSe Si chague accSs en 6criture« 

II est propose, dans le brevet amgrlcain US 
5 5,347,653 une mfitbode fournissant une perspective 
hlstorique k une base de donnges d'objets grSce k un 
verslonnement des objets stockfis alnsi gu'iL une indexation 
representative des objets. Cette m^thode de I'art ant^rieur 
propose de stocker intSgralement la demidre version de la 

10 base de donnSes et de stocker d' autre part les differences 
k appliquer k cette dernidre version pour obtenir des 
versions antSrieures. Le probldme pose par ce docxxment est 
la necessite d' appliquer les differences une k \me et en 
serie pour trouver I'etat de la base k line date doxinee. 

15 Cette contrainte inQ>ligue un coiit en temps important. 

L'art anterieur connait egalement, par la 
demande de brevet PCT WO 02/27561 (Oracle) , un systSme et 
un procede pour foumir un accds k une base de donnees 

temporelle. L' invention decrite dans ce document 
20 concerne un systdme et un procSde de visualisation 
selective de donnees en rangSes temporaires dcins une base 
de donnees de lecture constante. Les transactions 
sauvegardees provoguant des changements dans les donnees en 
rangees d*une base de donnees sent pistees et \m numero de 
25 changement du systgme stocke est assigne ll chaque 
transaction sauvegardee. Une selection demandee de valeurs 
de donnees en rangees de la base de donnees est executee 
ainai qu'irn temps d' interrogation ayant lieu avant le temps 
de sauvegarde d*au moins tine transaction sauvegardee. Les 
30 valeurs des donnees en rangees ordonnees contenues deuis les 
segments d'annulation stockant un identif icateur de 
transaction pour au moins une transaction sauvegardee sont 
recuperees . 
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L'art antfirieur connait Sgalement, par la 
demande de brevet PCT WO 92/13310 (Tandem 
Telecomraxmications Systems) , \m procgde de selection et de 
representation de donnSes variant dans le temps k partir 
d'un systSme de gestion d'une base de donnees fivoluant en 
fonction du temps, ledit proc6d6 produisant lane vue unifi6e 
sur un Scran d'ordinateur . Les donnfies provenant d'un 
enregistrement maitre relatif H une entitS particuli&re 
sont affich^es avec un attribut video ou de caractSre par 
dfifaut, et sont considgrges comme Stant 1 ' enregistrement Sl 
jour. L'accds a un enregistrement historique relatif ^ 
cette entitS fait que les donnSes relatives a des champs 
qui different des champs correspondants de 1 'enregistrement 
a jour sont superpos6es a de tels champs d 'enregistrement a 
jour mals avec un attribut vid6o ou de caractdre different 
de 1» attribut vidfio ou de caractSre par dSfaut. 
L' enregistrement Sl jour superpose devient un nouvel 
enregistrement H jour destine a d'autres superpositions. De 
la m§me fagon, l^accds Sl un enregistrement en suspens fait 
que les donnees relatives k des champs qui different des 
champs correspondants de 1 ' enregistrement k jour sont 
superposges k de tels champs d> enregistrement a jour mais 
avec un attribut vid6o ou de caractdre diff6rent de 
!• attribut vidSo ou de caract^re par dSfaut. Une plurality 
d^enregistrements historiques ou en suspens peuvent Stre 
composes de sorte que tous les champs modifies pour un jeu 
d« enregistrement a partir de la fin d'tine pSriode d6finie 
peuvent Stre superposes k un enregistrement k jour en une 
seule fois. 

On connait Sgalement, par la demande de brevet 
europSen BP 0 984 369 (Fujitsu), un mficanisme de stockage 
de versions datSes de donnSes . Dans ce mecanisme de 
stockage, les donnges sont stockfies comme une plural ite 
d'enregistrements, chaque enregistrement comportant au 
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moins \an attribute un tnarqueur de temps indiqpiant la duree 
pour lacjuelle I'attribut est valide, un temps d' insertion 
indignant le moment oil 1 ' enregistrement a 6t6 cr66 et un 
champ de type. Le champ de type indigue si 1' enregistrement 
5 est un enregistrement concrete un enregistrement delta, ou 
un enregistrement d' archive rempla^ant un ou plusieurs 
enregistrements qui ont 6t6 archives. On accede axix donn^es 
pour trouver une valeur d'attribut du point de vue d'un 
< temps specif ie en rSalisant une extraction des 

10 enregistrements qui possddent des temps d' insertion 
antfirieurs au « temps spScifig » et en construisant une 
valeur d'attribut k partir des enregistrements extraits. 
Des donnees sont mises Si jour uniquement en ajoutant des 
enregistrements concrets ou des enregistrements delta, sans 

15 modifier les valeurs d'attribut dans lee enregistrements 
concrets ou les enregistrements delta. 

La pr^sente invention entend remfidier aux 
inconv^niezits de I'art antSrieur en proposant un proc^dg de 
20 suivi de 1' Evolution des donnSes dans une architecture 
bas^e sur un S6BD, consistant en : 

• la materialisation des versions intermSdiaires et 
des flux de donnges rgsultantes des operations effectufies 

25 sur la base de donnees, au fur et k mesure de son 
evolution, au niveau de granularity eiementaire 
(enregistrement par enregistrement et attribut par 
attribut) / 

• la possibility de reconstitution et restitution 
30 « rapide » de tout Stat cadre historique d'origine de 

chaque version de donnSe et chaque operation (par 
« rapide » nous comprenons « sans temps additionnel 
perceptible lie d la restauration ») ; 
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comprenant : 



. des mficanismes de reconstitution de flux de 
dfipendance causale (de type source-deetinatlon) entre lea 
donnSes concernSes ; 

• d.a mieanlenes de notification de r«mi.e en oause 
d.B operation, du pass* en ca« d- Evolution des donnSes 
d' entree ; 

• des m§canismes de -execution ; 

et couvrant lea oaa partiouliera et lea extenaiona 
suivants : 
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20 



25 



30 



• prise en compte de 1' evolution etructurelle 
(evolution de schema) ; 

• prise en conqpte de I'gvolution des applications ; 
prise en cortqpte des applications existantes dans 

un cadre architectural flexible ; 

• achfimas d' Evolution graduelle d'une architecture 
a I'fichelle de I'entreprise ; 

• gestlon de versions virtuelles (families 
alternatives et hypothSses paralldles) . 

Le but principal de 1' invention est de 
permettre 1' exploitation des donn^es de la base selon des 
versions successives, tout en limitant les besoins de temps 
et capacity de stockage et t autoriser la restitution ^ la 
volge . 

one demarche habituelle coneiste a enregistrer 
des versions successives des bases de donnees, par example 
sous la forme de stockage pgriodique sur un support telle 
qu'une cartouche magnfitique de 1' integralite de la base de 
donnSes, dans I'Stat correspondant i la version courante 
La recherche d'une information nScessite la restauration 
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prSalable de toute la base, aL partir du support 
correspondant k la sauvegarde correspondante, puis a 
interroger la base ainsi restaurSe. Pour des bases de 
donn§es importantes telles gu' e^qploitSes dans le domaine 
5 bancaire, de 1' assurance ou de la gestion, le volume 
correspondant §l un Stat peut dSpasser le tSraoctet, volume 
gu'il convient de multiplier par le nombre d' Stats 
sauvegardSs . 

Cette solution est totalement inadaptSe Sl 
10 1' exploitation en tenqDS rSel. 

L' invention vise a rSpondre au problSme 
technique de 1 ' exploitation en temps rgel de bases de 
donnSes de grande volume. 

A cet effet, 1' invention concerne dans son 
15 acception la plus gSnSrale ion procSdg d' organisation d'une 
base de donnSes numSrigue sous une forme tradable, 
coraportant des Stapes de modification d'xme base de donnees 
numSrigues principale par ajout ou suppression ou 
modification d'un enregistrement de la base principale et 
20 des Stapes de lecture de la base de dozmSes principale, 

caractSrisS en ce que 

I'Stape de modification de la base de donnSes 
principale comprend une opSration de crSation d'au moins un 
enregistrement numSrigue comportant au moins : 
25 les identifiants numSrigues unigues des 

enregistrements et des attrlbuts concemSs de la base de 
donnSes principale, 

un identifiant numSrigue de I'Stat de la base 
de donnSes principale correspondant k ladite modification 
30 de la base de donnSes principale, 

les valeurs SlSmentaires des attributs gui leur 
sont affectSes ^ travers les opSrations SlSmentaires, sans 
procSder au stockage des attributs ou des enregistrements 
non modifiSs, 
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et d'ajout dudit enregletrement dans une base 
d'historisation interne compos6e d'au molns une table 
d'historisation interne, 

et en ce que l'6tape de lecture portant sur 
tout 4tat final ou antSrieur de la base de donnees 
principale consiste 4 recevoir (ou intercepter) une requSte 
originelle associfie Sl 1' identificateur unique de I'fitat 
vis6, a procfider 4 une transformation de ladite requSte 
originelle pour construire une requete modifiSe d'adressage 
de la base d'historisation con^renant les critSres de la 
requSte originelle et 1' identificateur de I'gtat vis6, et 
de reconstruction du ou des enregistrements correspondant 
aux critSres de la requSte originelle et a I'gtat vls6, 
ladite etape de reconstitution conslstant t retrouver les 
valeurs €16mentaires, contenues dans les enregistrements de 
la base d'historisation, correspondant aux critdres de la 
requite originelle [afin de r^duire les besoins de capacity 
de stockage et les tenqos de traitementj . 

Selon line variante, lesdits enregistrements de 
la base de donnfies d'historisation contiennent Sgalement 
des references i d'autres enregistrements de la base de 
donnges interne, dans le but de prSciser les liens de 
d£pendance dynamique de type source-destination constituant 
le flMx causal des interferences entre les versions des 
donnees . 

Avantageusement , ladite operation de 
modification de la base principale est une operation 
logique et ladite operation d'ajout dans la base de donnees 
d'historisation consiste k aj outer : 

un enregistrement identifiant I'etat de la base 
correspondant a 1' operation logique, 

autant d' enregistrements que de param4tres de 
1' operation logique. 
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un enregifltrement pour le rgsultat feventuel de 

1' operation logigue 

et k prficiser par xin lien de parents lee 

regroupements d' operations depuis le niveau 616mentaire de 
5 modification jusqu'au niveau de la transaction, en passant 

le nombre de niveaux semantigues nScessaires pour les 

applications . 

Selon une autre variante, la base de donn^es 

principale contient une ou plusieurs table (s), organisant 
10 les liens d' Evolution entre les identifiants des etats 

successifs et alternatifs de la base principale, 

de8tinge(s) ^ organiser les enregistrements de la base de 

donn^es interne . 

De preference, ladite ou lesdites tables des 
15 liens d' Evolution entre les Stats de la base principale 

contiennent des enregistrements spgcifiant les regies de 

Gorrespondance entre les enregistrements de la base de 

donnges interne d' historisation et les etats de la base de 

donnSes principale. 
20 Selon xin mode de mise en oeuvre particulier, 

ladite operation de lecture consiste 3. determiner ledit 

etat de la base de donnSes principale en se ref^rant aux 

dits identifiants et aux tables des liens d' Evolution entre 

les etats de la base principale. 
25 Avantageusement , une application interrogeant 

la base de donn^es principale peut specifier I'Stat de la 

base de donnSes principale dSsirS. 

L' invention conceme egalement une architecture 

de gestion de base de donnSes caracterisSe en ce que ladite 
30 application peut opSrer des modifications sur tout etat de 

la base principale et donnant lieu, dans le cas de la 

tentative de modification d'un 6tat anterieur, i la 

creation de nouvelles alternatives d' evolution de la base 
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de donnSes principale dont les donnSes seront gSnSrSes par 
la m§me base d' hlatorisation interne. 

Selon line variante, les liens de dgpendances 
servent de critSres de remise en cause desdites operations 
5 d^ja effectuSes. 



De preference, les mises ii jour effectuges sur 
des branches diffgrentes pourront Stre intfigrfies ou 
fusionnees dans le cadre d'un nouvel gtat « hSritant » 
10 desdites branches. 

Selon un mode de mise en asuvre particulier, les 
cas d' evolution de structure des dozmees de la base de 
donnees principale sont traites comme des cas particuliers 
d' evolution des donnees de ladite base, pour peu que la 
15 structure/schema de ladite base principale soit decrite de 
la fagon mentionnee pour les donnees, en tant que 
dictionnaire . 

Selon une autre variante, la base de donnSes 
d'historisation est exploree et interrogee par des 
20 applications a travers le mode natif du SGBD afin d'obtenir 
des informations comme par exemple toutes les valeurs 
historiques d'un attribut et toutes les incidences 
(dynamiques) de toute mise H jour et de naviguer au long 
des versions et des f liix de dependance dynamique et ceci de 
25 fa<?on classique, selon le langage d' interrogation en 
vicrueur, exige par le SGBD. 

On coraprendra mieux la prSsente invention a 
I'aide de la description, faite ci-aprds Sl titre purement 
explicatif, d'un mode de realisation de 1' invention, en 
30 reference aux figures annexees : 

La figure 1 illustre une architecture classique 
de communication entre une application et une base de 
donnees ; 
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La figure 2 illustre \ane architecture de 
communication similaire H celle de la figure 1 et 
comprenant les gl^ments nScessaires ii 1' application de 
1' invention ; 

5 lia figure 3 illustre les diffSrents moyens 

d'accSs k une base de donn^es organisSe de fagon tradable 
mtinie d'lm systdme selon 1' invention. 

La gestion des donn^es persistantes d'une 

10 entreprise (ou d'xme organisation au sens large) est 
gfinferalement confine H un logiciel spScifique appel6 aussi 
S6BD. Les applications inf ormatigues proposent atix 
utilisateurs des moyens ergonomigues interactifs capables 
de visual iser et faire §voluer les doxmges de la base de 

15 donnSes de 1' entreprise en conmiuniquant avec le SGBD. Dans 
les paragraphes suivants, nous rappelons les principales 
caractfiristiques de 1' architecture afin de positionner le 
cadre de notre procSdg de suivi de 1' Evolution des donnfies 
et d'en fixer le vocabulaire minimal. 

20 Le gestionnaire de persistance nScessaire pour 

notre systSme autorise le stockage des donnSes et leur 
reconstitution en mgmoire en conformity avec leur structure 
(dSfinie comme un ensemble d'attributs) et les valeurs 
saisies ou calcul^es. Les principaux SGBD Relationnels 

25 (mais aussi bien de type objet, rfiseau ou hiSrarchiques) du 
march§ sont des bons Candida ts pour le role de gestionnaire 
de persistance. Cette compatibility est d'ailleurs un atout 
de notre procSde qui peut aussi tirer ainsi profit de la 
base logicielle installSe dans 1' entreprise. 

30 ConsidSrons par simplification - et uniquement 

a titre d' example - 1' utilisation d'\in SGBD Relationnel. 
Celui-ci permet la representation des donnSes sous forme de 
tables (ou relations) . Les colonnes indiquent les attributs 
(ou champs) . Chaque colonne est caractSrisSe par un domaine 
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(entier, caractdre, date, flottant, etc.) et d'autres 
informations ^ventuelles conime la taille inaximale (pour les 
chaines de caractdres) . Certains attributs (un ou 
plusieurs) constituent la cle ou 1 ' identif iant de 
5 1' enregistrement . Dans la figure suivante, nous avons 
represents une table ^et nous avons indiquS les clSs en mode 
soulignS. Chaque ligne d'une meme tcJsle reprSsente un 
nouvel enregistrement (ou n-uplet) de structure uniforme, 
Chaque cellule reprgsente la valeur de I'attribut. Par 
10 exemple, « aaa » est la valeur de I'attribut Attributl du 
premier enregistrement dont la cl§ est 1001. 



Table 



Cle 


Attributl 


Attrlbut2 


1001 


« aaa » 


23/12/2001 


1002 


« bbb » 


24/11/2000 


1003 


« ccc » 


8/05/1989 



Les donnges sont insSrfies, lues, modififies et 
15 supprim€es k travers un langage de manipulation de donnges 
(SQL par exemple) • 

Le gestionnaire de persistance permet Sgalement 
la definition, la consultation et I'Svolution de la 

20 structure des donnSes, appel6e aussi schema de donnSes. 
Ainsi, les tables peuvent etre dgfinies, supprimSes ou 
restructurSes . Dans le dernier cas, des colonnes peuvent 
Stre rajoutges ou supprimSes. Parfois, il est utile meme de 
changer le domaine d'un attribut, ou d'autres 

25 caractSristiques analogues, ce qui peut impliquer des 
traitements implicites ou explicites de conversion des 
donnSes concemSes . 

Quelle que soit la representation physique des 
30 donnSes, la table est la reference logique de 
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reprfieentation des donnfies . Ainsi, les applications 
« voient » ggngralement les donnees sous la forme de 
taJ:>les. II est importiant de souligner que notre systdme 
tient a preserver cette representation logique afin de 
5 s' assurer la plus grande compatibility avec les 
applications existantes. Par exemple, apres avoir demande 
la connexion ^ une base de donnSes particuliSre, \ine 
application peut s'adresser a un gestionnaire de 
persistance avec une requete de type "select * from client" 
10 et recevoir en 6change \xn ensemble de donnees perroettant la 
reconstitution des donnees sous forme tetbulaire. 

PrScisons enfin qu'une base de donnSes 
reprSsente un Stat coherent du monde r6el represents. Les 

15 donnSes de la base fivoluent par S-coups dSclenchSs par des 
Svenements k travers des operations (insertion^ mise k jour 
ou suppression) regroupSes genSralement en transactions . 
Ces dernieres sont caracterisees par des propriStSs 
particuligres dites ACID (Atomicite, Coherence, Isolation 

20 et Durability) qui garantissent un certain niveau de 
qualite. 

Assurer la tragabilite des donnees persistantes 
revient H fournir des moyens permettant le suivi en amont 
et en aval du processus d' evolution des donnees. 

25 

Le processus d' evolution des donnees est une 
suite generalement non predictible d' executions 
d' operations eiementaires qui lisent, transforment et 
ecrivent les donnees de fa<?on repetee, donnant lieu le plus 
30 souvent Sl des interferences multiples et complexes qui 
rendent difficile et souvent impossible leur suivi. Assurer 
la tra<;abilite du processus revient H §tre capable de 
remonter a tout moment vers les origines (debuts) du 
processus, retrouver les valeurs dee donnees d'origine, 



wo 2004/025507 ^ ^ PCr/rR2003/002675 

pouvolr suivre et comprendre au fil des operations leurs 
coneSquences en termes d' impact de changements , En termes 
de quality de 1' information, la tragabilitg est tr^s 
prScieuse car elle permet de garantir la conformite du 
5 rSsultat d'une operation appliqufi avec le jeu de donnSes 
d'entr€e. 

Pour mieux comprendre I'Stendue de sa port^e, 
nous prSsentons une classification de la tra<?abilite selon 
10 des niveaux de plus en plus avancSs : 

• le premier niveau de tra^abilitS, que I'on peut 
qualifier d'616mentaire, est celui de la representation 
et du stockage des donnSes, II s'agit done de dScrire la 
15 structure, puis de stocker et d' identifier la donn^e, 

qu'il s'agisse d'une commande, d'un article ou encore 
d'une piSce mScanique, afin de pouvoir la retrouver plus 
tard, Ce type de fonctionnalitg est dSja assure par des 
logiciels spgcialisfis, appelgs SystSmes de Gestion de 
20 Bases de Donnfies (SGBD) . Le processus d' evolution se 

manifeste par 1' application successive d' operations 
61Smentaires comme la lecture, 1' insertion, la mise a 
jour et la suppression. Ces operations SlSmentaires sont 
gfinSralement regroupSes en transactions afin de 
25 maintenir la coherence des donnfies dans des conditions 

d' utilisation concurrente ou encore de reprise sur 
panne. A ce niveau, les mises k jour ont comme 
consequence naturelle la perte des valeurs existantes 
suite S leur remplacement par des nouvelles valeurs, 
30 puisque - par convention - a un mSme identifiant ne peut 
correspondre qu'une seule donnee (avec ses attributs) . 
Ce premier niveau dit eiementaire de tra?abilite est 
indispensable mais largement insuffisant. 



wo 2004/025507 



PCT/FR2003/002675 

14 



• le second niveau de tragabilitS autorise una donnSe H 
disposer en mSme temps de plusieurs versions (valeurs 
distinctes) . Cela amfiliore la tra?abilit6 puisqu' il 
devient possible de disposer S tout tnoment aussi bien 
5 des valeurs prficSdant que de celles suivant 1' execution 

d'une operation ou d'un processus, ce cfui facilite 
davantage la comprShension de 1' Evolution • Le 
versionement introduit une qualitS prgcieuse, puisque 
1' irreversibility n'est plus incontoumable (on permet 
10 1' Evolution des donnSes, sans perte des valeurs 

actuelles) . En plus des versions successives, il existe 
des versions alternatives. II arrive souvent qu'un 
utilisateur - aprds avoir remontS le fil d' execution 
d'lm processus - souhaite opSrer quelques changements 
15 sur I'Stat ant6rieur des donnSes. Dans ces cas, les 

tnficanismes de versionement permettent la prise en compte 
d' alternatives, ou des branches d' Evolution qui 
autorisent plusieurs suites possibles a partir d'un rn€me 
6tat de la base. Un systSme de tragabilit^ avsuicfi doit 
20 done intSgrer cet aspect, d'autsuit plus qu'une nouvelle 

branche permet de ne pas dStruire les prScSdentes et de 
preserver ainsi la tra^abilite des processus antSrieurs. 
II existe des nombreux travaux qui prennent en compte 
les donn^es dont les valeurs Svoluent dans le temps. Le 
25 domains des bases de donnges temporelles distingue 

clairement I'axe du temps de validity de celui du temps 
de transaction. Le temps de validite permet de pr^ciser 
par exemple qu'un tarif est valable de telle k telle 
date. Cette infoxroation est totalement indSpendante de 
30 la date de la mise k jour de la donnee qui la stocke 

dans la base et qui se situe dans le temps dit 
transactionnel . De par la nature specif ique de leurs 
problSmatiques, les mScanismes de prise en compte du 
temps de validity comprennent des solutions 
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d' interrogation et de mise H jour [Pxiblication de R. 
Snodgrass « The temporal query language Tquel » ACM 
Transactions on database Systems, Association for 
Computer Machinery. New York. USA] , proposent des 
op^rateurs dSdigs a la prise en compte d' intervalles 
(between, before, etc) , et traitent spgcif iquement les 
cas de mise a jour d' interwalles de temps pour une mime 
donnge qui impliquent la fusion ou la division [Demande 
de brevet europgen EP O 984 369 (Fujitsu)]. Par 
ailleurs, la representation et I'affichage des 
diffgrentes versions r^clament k leur tour des solutions 
spficifiques [Demande de brevet PCT WO 92/13310 (Tandem 
Telecommunications Systems)] qui facilitent la 
comprehension de 1' Evolution de donnSes individuelles, 
sans se prgoccuper de branches ou encore du critdre 
global de coherence collective des donn6es de la base 
dana I'espace de vereionement . En effet, ces aspects se 
situent en dehors de la problSmatique de tragabilite qui 
maintient vis-&-vis du versionement une s6rie 
d' exigences qui lui scmt propres et qui res tent tou jours 
non resolues. Citons enfin I'archivage et la 
restauration comme mgcanismes permettant de retrouver 
des etata antSrieurs de la base de donnSes. II est 
evident en revanche leur inadequation . face k la 
probiematique de tra^abilite, pour des raisons de 
granularite trop groasidre de suivi de 1' evolution 
engendraat des inconvenients insolubles de temps de 
reponse et d'espace de stockage. En conclusion, le 
versionement est egalement indispensable povir assurer la 
tra^abilite, mais reste, comme nous le verrons plus bas, 
toujours insuffisant. 



• un troisidme niveau de tra^abilite est celui des 
operations. Tracer une operation revient a laisser une 
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trace persiatante de 1' execution de ladlte operation, 
permettant une encore meilleure comprehension de la 
fa^on dont les donn^es ^voluent. On peut alnsl mieux 
expliguer 1' Evolution d'une commande entre deux 
5 versions, si I'on salt par exemple qu'il y a eu \ane 
operation de remise sur le prix total. 
La plupart des S6BD disposent de mScanismes de 
journalisation qui autorisent la consultation des 
operations effectuSes au niveau ei§mentaire. Pour 

10 qu'elles soient comprShensibles par les utilisateurs^ 

ces informations doivent Stre corrSlfees avec les 
operations de haut niveau, or le probldme de fond est 
que les entries du journal n'ont pas le m§me cycle de 
persistence c[ue les donnSes. Ainsi, le journal se trouve 

15 ggneralement en dehors de la base de donn§es et se voit 

rSguliSrement purge par 1' administrateur . La demande de 
brevet POT WO 02/27561 (Oracle) apporte une solution 
alternative Sl ce problSme, en proposant le stockage 
interne (dans la base de donnees) des transactions et 

20 des informations d'annulation de leurs effets (undo), ce 

qui permet de retrouver tout etat anterieur de la base 
de donnees par 1' execution dans I'ordre inverse de 
1' inverse des operations qui ont eu lieu depuis. Bien 
qu' interessante, cette technicpae peut etre trSs onereuse 

25 en termes de temps d' execution car, pour retrouver une 

version precise d'une donnee, elle defait toutes les 
operations qui ont lieu depuis, y compris celles qui ne 
la concement pas. De plus, elle n'est pas appropriee 
non plus pour obtenir la liste de toutes les versions 

30 d'une donnee. Enfin, elle interdit toute mise 3, jour k 

partir d'un etat anterieur de la base, ce qui ecarte les 
variantes et les branches alternatives d' evolution. 
Comme nous le verrons plus loin, dans la presente 
invention, les inventeurs ont opte pour une strategie 
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opposge : a la reception d'une requSte on procSde dans 
la prfisente invention k la transformation de celle*ci 
puis S une exgcuti'on sur les donnSes versionSes. Notons 
enfin, la nScessitS de disposer d' informations de plus 
haut niveau, foumies par exemple par les applications, 
afin d'obtenir une articulation entre la sSmantique des 
applications (application d'lme remise sur une commande) 
et celle du SGBD (mise H jour de I'attribut « montant » 
de la commande) . 
• le niveau le plus avanc6 de la tragabilitS est celui de 
la causalitS. II vise la materialisation des liens de 
transport d' information au niveau le plus Slfimentaire 
(le grain le plus fin) . Par exemple, si une operation 
quelconque O precede d la lecture de I'attribut A de la 
donn^e X, a la lecture de I'attribut B de la donnge Sl 
1' addition des dexix et au stockage de la valeur ainsi 
obtenue dans I'attribut C de la donnge Z, un lien causal 
serait capable de reconstituer ce transport 
d' information k travers les diffgrentes versions des 
donnges X, Y et Z, ainsi qu'aux diverses executions de 
1' operation O. Cette precieuse information permet de 
comprendre les details des evolutions, d'expliquer 
trans itivement les origines des modifications et de 
detecter les operations qui sont k refaire en cas 
d' evolution des donnSes d'origine. Elle est surtout 
importante parce que - contrairement aux techniques de 
journalisation - elle se defait de la contrainte 
sequentielle des operations pour se concentrer sur les 
dependances dynamiques engendrees par la causalite. On 
peut ainsi s'affranchir par exemple des milliers 
d' operations qui n' interf Srent pas avec les donnees qui 
nous Interessent. Enfin, elle s'avgre egalement 
extrSmement precieuse pour simplifier la fusion des 
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donxiSes sltuSes dans des branches diffSrentes et mieux 
identifier les v^ritables con£lits. 

Un caB particulier d' operation d' Evolution 
5 conceme 1' Evolution du schema q[ui consiste Sl faire 6voluer 
la structure des donnSes sans perte d' information 
[Roddick93 - Publication <x A taxonomy for schema versioning 
based on the relational and entity relationship models ^ 
Roddick, J.F., Craske, N.G. and Richards, T.J. 1993.]. De 

10 fagon analogue aux donnSes, le suivi de 1' Evolution de leur 
structure sera mieux assure si le mScanisme de versionement 
de suivi des operations et des traces causales s' applique 
^galement aux informations d$crivant la structure. Des 
mesures particuliSres d' organisation des donn^es et des 

15 metadonn^es [Publication oc Extracting delta for incremental 
data warehouse maintenance » Ram P et al. Data Engineering, 
2000 • ] seront n€cessaires • 

Un des objectifs de la prSsente invention est 
20 de proposer un proc6dS faiblement intrusif et progressif 
d' organisation d'une base de donnSe num^rigue sous une 
forme traq:able. Nous visons 1' assurance des niveaux 
successifs de tragabilitS d^crits ci-dessus, sans pour 
autant imposer la refonte des applications existauites. 

25 

En d'autres termes, I'objectif poursuivi par 
1' invention est de fournir aux applications inf ormatiques 
et a leurs utilisateurs la capacite de suivre de fa<?on 
precise les donn^es tout au long de leur Evolution, en 
30 tra<?ant leurs histoires de fagon complete, aussi bien sur 
le plan individuel (versions interroediaires et liens de 
succession) que sur le plan collectif (evSnements 
dgclencheurs et liens d' interdSpendance dynamiques issus 
des interactions entre les versions des donn^es) , en la 
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positionnant dans le cadre cohSrent de son dgroulement 
originel • 

II s'agit done de fournir des liens de 
causality S un niveau 616mentaire oH I'on puisse suivre 
ais^ment le flxax causal des transformations et verifier la 
validity de chaque operation intermfidiaire sous la base des 
donnSes d'entrfie, du traitement appliqufi et des donnSes 
rSsultantes, de telle fapon que la reconstitution de tout 
Stat du passe soit immfidiate, 

De plus, le procedS selon 1' invention utilise 
xm cadre architectural flexible, aussi peu contraignant et 
intrusif que possible afin de fournir une trds large 
applicability au procSde proposg et une aussi large 
compatibility que possible avec les proc6d6s de stockage et 
manipulation des donn§es courantes. 

Afin d' assurer le suivi de 1' Evolution d'tone 
base de donnSes dite « principale », le procedg selon 
1' invention permet de faire en sorte qu'elle repr§sente non 
pas seulement un mais tous les etats coherent s successifs 
et/ou altematif s n^cessaires du monde rfiel represents dans 
son Evolution, tout en prSservant les propriStSs ACID, 

Dans ce but, 1' architecture mise en ceuvre pour 
1' invention est illustrSe figure 2 et est constituSe comme 
suit : 

un journal (J) organisS sous la forme d'une 
« base de donnSes interne d'historisation » constitue d'une 
table ou d'un ensemble de tables dSdiSes au suivi de 
1' evolution et basSes sur un mode de stockage universel k 
schSma stable (independant de la representation logique des 
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donnges applicatives) et particulidrement adapts k la 
reconstitutlon k la volSe des donnSes. 

un moniteur de transactions (M) et d'£vSnements 
capable de d^tecter toute demande d'gvolution de valeurs et 
5 de structure trajismise IL la base de donnSes qui rajoute au 
fur et a mesure dans le journal d^diS des entrees 
caractSrlsant 1' Evolution ^ISmentaire des donnSes 
(identltg, attribute valeur, SvSnement dSclencheur et 
dgpendeuices dynamiques) 

10 un module de reconstitutlon (R) Sl la vol6e de 

I'etat de la base de donnges selon im Svfinement cible ; le 
systeme est muni dans ce but d'un curseur (C) dedi^ H la 
selection de I'fitat recherchS, 

cas partlculier : dans certains cas, 11 peut 

15 s'avSrer utile de matSrlaliser la vue de la base dite 
« courante » ou « prlncipale » sous la forme des tables de 
structure sp^cialls^e, par exemple pour permettre des 
performances SlevSes et une compatibility totale avec des 
applications exlstantes (notamment afln de permettre 

20 1' usage des procSdiires stockees et autres dSclencheurs ou 
triggers qu'xine application peut exlger pour fonctionner 
correctement) • 

Optionnellement , 1 ' architecture comprend 

25 ggalement : 

• un systems de suivl de la conformlte (SC) des 
applications avec les etats de la base et de son schema 

• des outils d' inoculation (I) automatique dans les 
applications d' instruct ions dSdi^es au suivi des 

30 d^pendances dynamiques (capture des flux de donnSes) 

Le journal (J) d'Svfinements (ou la base de 
donnees Interne d' historisat ion) est constitug 
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principalement d'vme table k structure indSpendante de 
celle des donn^ea applicatives. Les coloimes eont : 

• ton identifiamt iinique de 1' enregistrement de la 
table logique concern^ par la ligne de journal, appartenant 
h la cl6 principale 

• \in identifiant de I'attribut dans le schSma, ou 0 
pour 1' enregistrement lul-mSme, appartenant ^ la clS 
principale 

• un identifiant universel d'6v6nement, increments 
automatiquement, appartenant Sgalement ^ la cl§ principale 
du journal et correspondant a I'Stat de la base principale 

• xin champ valeur dgdiS au stockage des valeurs 

Le r61e du moniteur (M) est de dStecter et 
d' interpreter correctement chaque demande d' Evolution en 
rajoutant 1' information correspondante dans le journal 
d' Svdnements (J) . 



Ejcemples d^Svolution de valeur 





ID 


Attribut 


UEID 


Valeur 


Comment a ire 


- insertion 
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0 


52 


53 


ID table 


d' enregistrement 
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- mise & jour 


110 


1 


853 


1001 


No du client 


d'un attribut 












- mise d jour 


110 


2 


854 


"aaa" 


Nom du 


d'un attribut 










client 



- suppression 


110 


0 


981 


0 


d'un 










enr eg i s t r ement 
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Dans le langage d'gchange avec xine base de 
donnfies SQL, les trois premieres lignes du taJoleau peuvent 
dtre l'e££et de la reguSte sulvante : 

5 insert into Client (no_client, nom_client) 

values (1001, "^aaa") 

One telle requ&te est trait^e comme suit : 

10 • analyse syntaxlgue (parsing) de la requite 

• r6cup6ration depuis le schfima des identifiants 
pour la tcible client (53) ainsi que pour les attributs 
« no_client » (1) et « nom_client » (2) 

• insertion des trois lignes dans le journal 

15 

La derniSre ligne peut Stre obtenue par 
1 ' instruction suivante : 

delete £rom Client where No_client=1001 

20 Une telle requete est traitSe comme suit : 

• analyse syntcocique (parsing) de la reG[u€te 

• r6cup6ration depuis le schema des identifiants 
pour la table client (53) ainsi que pour I'attribut 

25 4J no_client » (1) . 

• rScupSration de 1' identif iant de 1' enregistrement 
du journal ayant la valeur 1001 pour I'attribut no 1 

• insertion dans le journal de la demiere ligne 
(en utilisant le code 0 pour la valeur) . 

30 
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Bxemples d^Svolution de schSma 
create table Client (no_cllent int 

Creation d'une 

nouvelle table 



Ajout d'un 
attribut 



ID 


Attribut 


OBID 


Valeur 








A 
U 


O C O 


8 




1 


o c o 


« Clien 
t » 


54 


0 . 


254 


9 


54 


1 


255 


« no_cl 
lent » 


54 


2 


256 


Int 


54 


3 


257 


PK 


54 


4 


258 


53 



primary key) 
Commentaire 

ID table 
des tables 
Norn de la 

table 
ID table 

des 
attribute 

Norn de 
1 ' attribut 
Domaine 

CIS 
primaire 
ID table 



alter table Client drop coltimn no client 



Suppression 
d'un attribut 


54 


0 


278 


0 


Code 
suppression 


Suppression 
d'une table 


drop table Client 






53 


0 


293 


0 


Code 
suppression 


Autre s cas : 
d^placement 
d' attribut 














54 


3 


308 


22 


Mise 3. jour 
ID table 



L'exemple dficrit ci-dessus concerne un cas 
contplexe, sans Equivalence en una seule operation SQL. Un 
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outil de gestion interactive peut en revanche permettre de 
tirer \m rgel bSngfice de cette caracteristigue . 

Comme on peut le retnarquer, chague gvgnement 
5 qui tend IL modifier la base de donn^es logigue finit par 
cr^er iine ou plusieurs entries sous la forme de nouvelles 
lignes (ou enregistrements) dans le journal. Ceci garantit 
que rien ne se perd et que toute suppression ou mise Sl jour 
logique ne se traduit pas en une suppression physique. 
10 Ainsif les donnSes du pass^ peuvent £tre rScup^rges. Un des 
avantages de cette organisation est la constitution 
concurrente de vues comme les livres de comptes qui 
bloquent g€n£ralement I'accSs en mise h jour d'autres 
utilisateurs. 

15 

Remarquons Sgalement 1' uniformity de la 
structure de stockage des informations : les donnSes sont 
stockees en effet de fagon identique, qu' il s'agisse de 
I'Svolution des valeurs ou de celle des structures. Ceci 

20 veut dire que du point de vue logique, il est possible de 
reconstituer aussi bien les tables logiques que leurs 
structures, sur la base d'un meme mScanisme. Par ailleurs, 
le fait d'inclure le journal dans la mSme base de donnSes 
que la base principale permet de garantir sa coherence 

25 relative de par le mScanisme trans act ionnel assure par le 
SGBD. 

Le module de reconstitution (R) a en charge 
justement la restitution en format logique des donn^es en 
30 fonction d'un paramdtre de type 6v6nement, k partir du 
journal d'ev§nements (J). 

Par exemple, considfirons que 1 ' application 
soiihaite obtenir les donn^es de la table Client telle 
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qu'elle Stait juste lors de I'fivgnement 854. Cela implique 
au pr^alable la eSlection de l'6v6nement 854 par le cxirseur 
d'Svfinementa (c) . Par la suite, la requSte "select * from 
Client" est transmise au SGBD mais transformfie par le 
module (R) en une requSte plus complexe, obtenue de la 
fagon suivante : 

• reconstitution du schema correspondant : la 
requSte porte sur la table Client ; le systSme doit done 
verifier 1' existence de la table Client au moment 
historique positionnS par l'6v6nement cible et ricup^rer 
les attributs de cette table logique ; (une optimisation 
est possible en gardant le schema en cache) 

• r^cupgration des enregistrements dont le champ 
Attribut = 0 crees et non supprimfis « avant » I'evfinement 
correspondant a I'Stat cible, (valeur = 0 pour le code de 
suppression) et attaches a cette table. Dans le cas des 
alternatives, « avant » ne conceme que les 6v6nements 
situgs sur la mgme bramche. 

• rScupSration de tous les enregistrements dont le 
champ Attribut <> 0 attaches aux pr6c6dents et antSrieurs H 
l'6vgnement cible. 

• reorganisation du flux de donnfies restitutes et 
regroupement par enregistrement logique, c'est-t-dire dans 
notre cas, par client. 



Dans un mode de realisation de 1' invention, il 
est possible de faire des requgtes de modification sur des 
etats passes de la base de donnees principale de fa^on k 
creer une arborescence des versions de la base de donnees 
traitee . 



En plus des valeurs et des evenements, le 
journal peut accueillir les invocations d'operations. Cela 
peut Stre realise par la representation des operations sous 
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la forme de tables logiqpaes, o\l chague operation correspond* 
a un nom de table loglc[ue et chaque argument correspond H 
un attribut logique. En appliquant ce schema de 
correspondance, 1' application peut envoyer au joxirnal (par 
5 exemple, par 1 ' intermSdiaire d'une API : « Application 
Programming Interface interface de programmation 

d ■ applications) les informations necessaires a la 
tra<?abilit6 des appels d' operation de fagon analogue S la 
manipulation des donnges logiques (mais cette ttche peut 
10 Stre automat is^e et confige d un post-processeur, au 
compilateur, au processeur ou encore la machine 

virtuelle) . 



add (2, 
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Les appels d'op6ration permettent de raccorder 
la sgmantique des actions de 1' application atax 6v6nements 
enregistrSs dans le journal. Comme nous le verrons plus 
tard, cela facilitera le positionnement du curseur sur des 
repdres signif icatif s du point de vue de I'utilisateur. 

De surcrolt, les points de validation des 
transactions peuvent Stre traces sous la forme 
d'opSrations. En effet, il est recommandS que le curseur se 
positionne exactement sur ces points et non pas entre deux 
operations d'uae mgme transaction. La coherence du rgsultat 
en depend. En revanche, des applications comme les outils 
d'aide 4 la conception peuvent trSs bien bSnSf icier des 
Stats intermSdiaires, rSputSs incohgrents, dans un but 
explicatif, et bSngf icier ainsi de mScanismes de type 
« transactions longues ». 

PrScisona enfin que les operations sont relifies 
par des references (non-representees dans les tableaux) 
vers les operations parentes de telle sorte que I'on puisse 
tracer Sgalement leur appartenance a 1' execution d'une 
operation de plus haut niveau. Ainsi, il sera possible de 
reconstituer 1 ' appartenance des operations, depuis le 
niveau eiementaire des evSnements et jusqu'au niveau des 
transactions, en passant par autant de niveaxax d' invocation 
que necessaire pour les applications. 

L' invention concerne egalement la 
materialisation des liens de causalite. 

Le fl\ix des dependances causales doit itre 
constitue dynamiquement par les operations de lecture et 
mise a jour en respectant les rSgles suivantes : 



La manipulation des donnSes doit 
systematiquement considerer aux c6tes des donnees lues 
leurs references d'origine et les transporter tout au long 
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du £lux de donnees et contrdle. L' application dolt done 
prendre en charge cet aspect, en ajoutant 1 chacapie 
instruction de manipulation son 6gulvalent de tramsport de 
rSfSrences, par exemple par 1 ' intermSdlalre d'une API, 
5 L' automat Isation de cette tSche peut etre rSalis^e par un 
post-processeur et/ou par des extensions du processeur ou 
de la machine virtuelle. 



Lors de 1' insertion d'une donnSe physique, les 
10 references du flux I'ayant alimentSe doivent Stre stock6es 
sous la forme d'line liste d'SlSments de type ID-attribut- 
UEID, aux c6t6s de I'attrlbut valeur, et ceci pour chaque 
enregistrement physique du journal. Le tableau suivant en 
fait 1 ' illustration. Une liste vide correspondrait ^ 
15 1' introduction d'une valeur de I'extdrieur du aystime (par 
exemple, par la salsie effectu^e par un utillsateur ^ 
travers une Interf ace-Homme-Machine) « 



ID 
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L' implementation des sources dans le journal 
peut trSs bien §tre rgalisge par 1 ' interra6diaire d'un 
journal additionnel (ou sous-table), organist de fagon 
tabulaire, et ceci pour des raisons d' optimisation de 

5 performances, selon les techniques en vigueur dans la 
discipline des bases de donnies. 

L' interpretation du flux se fait de manifire 
simple : la valeur d'une donnSe depend des valeurs des 
donnSes sources lues aux moments r€f6rencSs par les 

0 6v#nements UEID correspondants . On peut done dire que les 
sources matSrialisent les liens de causalitS ^Igmentaires . 

L' invocation des operations peut Stre trac6e de 
la mSme maniSre. Voici S titre d'exemple, I'appel de 
1' operation Add (mentionnge prScedemment) avec les 

5 arguments Client .Attr3 et la constants 7. 



ID 


Attribut 


DBID 


Valeur 


Sources 


62 


0 


401 


57 




62 


1 


402 
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ZD 


Attribut 


UBID 


11 
0 


3 


543 


62 


2 


403 


7 






62 


999 


404 


10 





Commen t ai r e 
ID operation 
« add » 
Premier 
argument 

Second 
argximent 
Valeur de 
retour 



Le contr61e de validitS des operations peut 
St re effectuS par rapport aux donnges en vigueur. Par 
exemple, si la valeur de 1' attribut Attr3 du Client lio 
change aprSs I'exficutlon de 1' operation « add les 
rSsultats envoy§s par celle-ci ne peuvent plus Stre 
considerSs comme conformes. On dit gu'il y a « remise en 
cause ». Dans le cas d'une Evolution sans alternatives. 
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cela peut Stre vSrififi grSce Sl une simple comparaison 
d'UEID entre les sources des arguments et les demldres 
valeurs des sources r§£grenc6es. 

5 Pour qpie cette information de tragabilit^ soit 

entiSrement efficace pour I'utilisateur, il est utile de 
minimiser les constantes, c'est-^-dire les valeurs saisies 
« arbitrairement ». L' application doit ainsi privilfegier 
dee syst^mes d' identification par liste de choix, par 

10 pointage, par glisser-dfiplacer, etc., ou par toute autre 
technique cjui amSliore a la fois I'ergonomie de 
^'application et qui permet implicitement 1' assurance d'un 
suivi sans discontinuite du flux inf ormationnel • En 
rgalitg, ces techniques d' identification sont largement 

IS rSpandues car elles assurent des avantages de r^ferencement 
statique prfivu dans les bases de donn^es de faqion courante. 

Cette caractSristique du procSdg permet de 
surcroit la mise en place d'un systdme d' optimisation 

20 automat ique, qui • sur la base de la verification 
systSmatique de la validity des sources - permet de 
renvoyer le rSsultat calculS pr6c6demment , sans reexScuter 
ef f ectivement 1' operation. La mise en place d'une telle 
solution implique 1' introduction des references vers les 

25 operations appelantes (ce qui peut etre fait a travers des 
arguments suppiementaires) et S condition que le temps de 
verification soit inferieur a celui d' execution (des 
statistiques de performances peuvent Stre maintenues a 
titre informatif et exploitees ef f icacement) . 

30 

La notification automat ique des « remises en 
cause » pourra Stre mise en place sur la base des 
informations de validite des versions des donnees par 
rapport aux flux. Ainsi, pour une operation, une classe 
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d' operation, une cible ou xrne soiarce donnSe, des alerteurs 
de coherence de flux poaarront notifier lea applicatioM par 
des messages synchrones ou asynchrones. 

5 La r6-exgcution consiste en une nouvelle 

invocation explicite d'une operation donnfie sur le module 
d'une invocation precgdente, mais sur la base de nouvelles 
valeurs. Dans tous les cas, elle donnera lieu a des 
nouvelles valeurs pour les donnfies, les operations et les 
10 sources tracges. 



Le procSdg selon 1' invention est spgcialement 
congu pour g^rer de fa<?on op€rationnelle I'historisation au 
fil de I'eau et la restauration a la volSe. De plus, la 
15 gestion des volumes de stockage est facilitSe et optimisfie 
par un ensemble de facteurs : 

• seules les valeurs attributs qui changent sont 
stockSes (la redondance est ainsi minimisSe) 

• lea volumes nScessaires de stockage 
20 suppltfmentaires augraentent de fagon lingaire avec le nombre 

des attribute modififia ou supprim^s et ne dependent pas des 
volumes de donnSea insfirgs dans la base ; ce facteur 
autorise une utilisation tr§s avantageuse pour xin trds 
large spectre d' applications. 

• enfin, lea purges trSs pertinentes peuvent gtre 
op6r6es aelon lea donn^ea marquees comme remises en cause 
par les liens de tragabilitfi de type source -destination, 
mais cette operation doit Stre pilotee par les applications 
en fonction de la aSmantique des remises en cause. 



30 



Pour des raisons de simplification du discours, 
dans 1' example pr6c6dent, nous avons fait I'hypothdse 
implicite d'une organisation sgquentielle des evSnements et 
done des Stats de la base principale (selon un ordre 
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total) . Ainsl, pour verifier la valid! t§ d'tine source, noxis 
avons 6voc[uS comme solution la comparaison simple des 
identifiants universels d'6vSnement (UEID) . 

En rSalite, notre procedS autorise un vaste 
5 ohoix d' organisation des versions, comme par exenqple : 

• Arborescence : chaque Sv^nement a un §v6nement 
parent. La valeur d'une donn^e associ£e Sl un ^vSnement peut 
Stre obtenue par une remontfie logigue des parents jusgu'd 
la valeur la plus proche. 

10 • Graphe oriente sans circuit : analogue Si 

1' arborescence, cette organisation permet k une version 
d' avoir plusieurs parents diffSrents. Les ambiguit§s de 
resolution peuvent Stre levSes par des rdgles pr^dgfinies, 
bashes sur des critdres de priority des branches ou sur 

15 tout autre caract^ristique de la donnge (son type, etc.) 

Les evolutions des branches diffSrentes peuvent 
§tre fusionn6es en faisant appel Sl la rS-exScution des 
operations . 

Les versions virtuelles sont des branches 
20 d'evenements predgfinies qui permettent la constitution de 
configurations parallSles pouvant bSngficier simultangment 
des evgnements appliques Si une ou plusieurs branches dites 
« de reference Autres caracteristiques : 

• Les eventuels conflits sont evites par la 
25 separation des evenements par nature en branches de 

reference selon le module evoque dans 1 ' organisation de 
graphe oriente sans circuit. 

• La materialisation de ces configurations n'est 
pas reelle car les evenements ne sont pas dupliques 

30 physiquement (la propagation est logigue) . 



L' architecture mise en oeuvre pour la 
realisation de 1' invention peut aussi comporter les modules 
suivants 



10 



15 



WO 2004/025507 

33 



PCT/FR2003/002675 



• un systSme de suivi de la confomitg (SC) des 
applications avec lee 6tat8 de la base et de son schSma. Le 
principe est basS sur 1 ' enregistreraent d'un identifiant de 
version de 1 'application afin de declarer un niveau de 
compatibility avec le ou les 4tats correspondants au schema 
de la base principale 

des outila d' inoculation (I) automatique dans les 
applications d' instructions dgdi^es au suivi des 
dfipendances dynamiques (capture des flux de donn«es) : 
prS/post-processeur ou Machine virtuelle fitendue 

des composants visuels specialises dans la 
navigation et 1' exploration des fitats de la base (non- 
reprgsentes) . 

L' invention peut Stre implementfie de plusieurs 
manidres selon le contexte dans lequel elle est intggrSe ^ 
line application. 

^° figure 3 prfisente une architecture qui 

autorise trois niveaux d' integration de la tra^abilitg, de 
bas en haut : 

Les applications existantes peuvent continuer ^ 
accSder & la base de donnges (date « principale *) de la 
25 mfime manidre. La base peut soit garder sa structure 
d'origine et redlriger les accSs a un journal associg (dit 
base interne) , soit Svoluer vers une organisation physique 
de type journal et offrir des vues ou un driver ayant en 
charge la translation des requStes et des rSsultats. 

Les applications existantes pourront §tre trds 
facilement munies d'un « curseur ^ k condition que I'accSs 
aux donnSes soit centralise (ce qui est gengralement le 
cas, par exemple a t ravers un driver unique). Dans ce cas, 
1' application pourra offrir des moyens d'acces automat iques 
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aiox donnSes de la base (impl^mentge dSsormais sous la £orme 
d'un journal) et permettre a\ix utilisateurs d'actioxmer un 
curseur qui positionnera les lectures sur le repdre 
6v6nementiel d6sir6. Des l^gSres adaptations pourront avoir 
5 lieu afin d'accorder la granularity des gvSnements avec la 
sgmantigue de 1 ' application. 

Les nouvelles applications, entiSrement 
construites sur la base des technologies d' inoculation de 
generation de traces b6nSf icieront inqplicitement du niveau 

10 le plus avanc6 de tracrabilitS offert par ce procgdS 
comprenant le suivi exhaustif de 1' evolution des donn€es et 
de leur structure. Pour que le suivi de 1' Evolution des 
applications soit assure au mSme niveau, il suffira de 
recourir ^ des techniques declaratives de representation 

15 des sources, de les confier au mSme journal et de les faire 
manipuler par un outil d' assemblage muni lui-mgme d'un 
module de tragabilite selon ce m§me precede. 

Cette architecture permet d'atteindre 
graduellement des niveaux de tragabilite des donnSee 

20 persistantes de plus en plus eievees : 

• initial : representation et persistence 
(indispensable, prealable) , assure par le systSme initial 
de persistence 

• journalisation des evSnements (utile, reprise sur 
25 panne §. court terme, mais pose un probldme de 

reconstitution rapide des etats passes) 

• historisation et versionnement (utile, car les 
valeurs stockees sont multiples et peuvent comporter des 
variantes mais cette f onctionnalite gendre des problemes de 

30 reconstitution en mode compatible avec le mode initial) 

• evolution structurelle : le suivi des evolutions 
des donnees et du schema de la base de donnees principale, 
compatible avec le mode initial 
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• dgpendance causale : la detection des flux de 
dSpendance dynamique et des lienB de causalitS entre les 
donnSes de la base de donafies d'historisation (joumalisSe) 

L' utilisation de branches off re la possibility 
de crger des alternatives d' evolution de la base de 
donnfies. Dans le m§me temps, cela ISve des nouveaux 
problimes quant k la tra?abilit6. Bn effet, supposant 
qu'aprSs la separation des branches A et B, la donnSe X 
soit modifiee dans la branche A k travers I'opSratioa O. On 
peut alors souhaiter renvoyer sa nouvelle valeur dans la 
branche B, comme si elle avait eu cette valeur au moment de 
la separation des branches. Cette operation, appelSe 
rafralchiesement est trSs utile pour des nombreux cas oil 
des donnees institutionnelles de reference sont revues d 
des intervalles plus ou moins reguliers. Leur integration 
peut poser alors des problSmes d' interference avec les 
operations effectueee entre temps. Par exemple, si aucune 
operation ayant eu comme source ou destination la donnee X 
dans la branche B n'a pas ete effectuee entre temps, on 
peut sereinement considerer qu'il n'y a pas d' impact. En 
revanche, si c'est le cas, il faudra alors decider 
(explicitement ou implicitement) quelle est 1' operation qui 
est prioritaire et refaire les autres. Ces conflits sont 
aisement detectables grSce aux liens de dependance 
dynamique. La semantique associee sera apportee quant a 
elle par celle des operations ayant provoque ces 
dependences. La simple comparaison de 1 ' identif iant 
universel des traces d'operations permet d'evaluer 
30 I'anteriorite et de la confirmer ou de I'infirmer. 
L'utilisateur (ou 1' application, t travers un systSme de 
regies predefinies) peut ainsi trencher en connaissance de 
cause. Le cas de la fusion de branches est tout S fait 
analogue . 
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Prgcisons que cette technique est plus 
intgressante que le verrouillage anticipS d'une donnSe^ 
puisque, dans des nombreux cas, lea opgrations a venir ne 
sont pas previsibles et leurs donates cibles encore moins. 
5 La possibility de crSer des branches est d'ailleurs un 
moyen qui vise I'Svitement au moins temporaire des conflits 
et qui permet de repousser Sl plus tard leur resolution. 

Les branches virtuelles - qui sont par 
definition rafraichies en permanence par leurs branches 
10 « parentes » - bgnSficient automat iquement du 
rafra£chissement des donnSes dans leurs branches parentes, 
y compris des operations de dgbranchement (creation de 
nouvelles branches) qui s'opSrent (virtuellement , bien 
entendu) en mSme temps sur les branches virtuelles. Par 

15 exemple, si la branche B est virtuelle, alors toute 
operation effectuSe sur la branche A se rSpercute 
automat iquement sur la branche De plus, si I'on cree une 
nouvelle branche A2 partir de A, celle-ci aura comme 
effet la creation d'une sous-branche analogue B2 a partir 

20 de B. II est important de souligner le caractSre virtuel de 
ces rafraichissements. Cela veut dire qu'en realite aucun 
traitement n'est rfiellement effectuS. Le seul effet reside 
dans le fait qu'une prochaine requSte sur la branche B aura 
un rfisultat enrichi (qui tient coropte des donn^es 

25 rafraichies). Pr^cisons enfin qu'en cas de propagation 
automatique, il n'y a pas de resolution automat ique de 
eonflit, sauf si des rdgles ont ete predefinies. Dans 
certains cas, on peut decider a I'avance que, par defaut, 
ce qui a ete modifie explicitement dans la branche 

30 virtuelle reste prioritaire par rapport aux donnees 
provenues par raf raichissement . 

La fusion de donnees complexes est un cas k la 
fois plus sophistique et plus realiste puisque le plus 
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souvent, le crit^re de decision majeur du choix de versions 
en vue de la resolution du conflit est le contexte 
ConsidSrons que la donnfie X est une comtnande et que les 
donnSes Yi et Y2 sont deux de ses lignes de commande. Si un 
. nouveau tarif pour 1' article 21 est propose dans la braache 
« parente puis propagg dans la braache en question, on 
doit alors dScider si celui-ci remet en cause la valeur de 
la commande X, sachant que la ligae Yl fait r6£6rence 
justement A I'article Zl. La rgponse sera doanfie par la 
rfegle de gestion en vigueur pour les commandes. Itoe telle 
rSgle pourrait s'exprimer par exemple sous la forme 
suivante : * si la commande se trouve dans l'«tat pay*,- la 
commande reste intacte, autrement, mes mises & jours 
tarif aires s'appliquent aussit6t Prficisons que cette 

rdgle n'a pas a tenir compte des notions de version, 
branche ou encore de trace causale, ce qui souligae une 
nouvelle fois le trSs faible niveau d' intrusion de notre 
proc6d£. 

En coaclusion, la disponibilitfi des traces 
causales permet de configurer de fa<?on plus fine les 
difffirentes possibilitfis de fusion, tout en respectant 
scrupuleusemeat lea processus et tout en apportaat la 
preuve irrefutable de ce respect. 

Le spectre des applications de 1' invention 
couvre la plupart des cas oa il est utile de suivre 
1' evolution des donnges persistantes, des applications de 
gestion et jusqu'aux systSmes de gestion de fichiers, en 
passant par des outils de conception reposant sur des 
rSfSreatiels (ou repository), ou au-delt des besoias de 
persistence, pour peu que le suivi de 1' Evolution est 
utile. 
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L' invention est d£crite dans ce (jui pr^cSde 4 
titre d'exetnple. II est entendu que I'hotnme du mdtier est a 
mSrae de rSaliser diffSrentes variantes de 1' invention sans 
pour autant sortir du cadre du brevet. 
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^^''''^'^^ <i'organisation d'une base de donnfies 
numSriques sous xme forme trar-aKi wnnees 
5 den,«H4 4:4 tradable, comportaat des fitapes 

r.r^,":: " ^^^^ p-^-ip^i. 

.nr.gx.tre™.„t la base principale et d,. *t.pe. 

lecture a. l. b... de donn^ee principale, 

caractSrlse en ce que 

^'^^^P^ modification de la ba»« .q* ^ 
principale co^rend operation de crj.ir;."^" 
«reg«tre«ent num^rique con^ortant au ».in. , 

lea identifiante numSriques uniaue. 

enreglatremente et des att,ih„— unique, dea 

J . attribute coneemSs de la baaa d. 

IS donnSes prinelpale, " 

b... ^'^"""''= n™,*rlgue unique de l-.tat de 1. 

baae d. donn*.. principale correspondent . ladit, 
mcdiflcation de la baae de donnSes principale. 

- .»nt ..fectAV :tr'r."ltr"""."^ "'"^"'^ 

P«c*der au ..^^^Z'. Z.^ZTV""^"'"""' 

noa modlfi*.. =ttrxbuts ou de. enregi.trement. 
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d-hi.^ • enregistrement dans une b..e 

d hx.torxa.tion Interne oo,^s.e d-au ^olns une table 

tout *t.t T " ""^ '"""'^ -ur 

nriV , °"" ""-^^"^ la baae de donnSe. 

llZTl * """^'^ ^"--P-r. une requs" 

Via! I T * * ^'^'■"""cateur unique de Wtat 

olllLL^ " * ^»-^°-atio„ de ladite requite 

rfa b d.adre!^age 

reUt. ■ =-P— lea crit.res de la 
requite origxnelle et l-identificateur de L.tat viai, et 

at rrirrrV -e^ent. correspondent 

aux crxtire. de 1. requite originelle et a l-itat vl.s. 
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ladite etape de reconstitution consistant H retrouver les 
valeurs €lgmentalres, contenues dans les ezireglstrements de 
la base d'historisation, cozrreapondant aux critdres de la 
requSte originelle [af in de rfiduire les besoins de capacity 
5 de stockage et les temps de traitement] . 



2. ProcSdS d' organisation d^ime base de donn^es 
numSrique sous line forme tradable selon la revendication 1, 
caractSrisfi en ce que lesdits enregistrements de la base de 

10 donnSes d' historisation contiennent ggalement des 
references H d'autres enregistrements de la base de donn^es 
interne, dans le but de prgciser les liens de dependance 
dynamique de type source -destination constituant le flux 
causal des interferences entre les versions des donnges 

15 

3. Proc^dS d' organisation d'une base de donnSes 
numSrique sous xme forme tradable selon I'une quelconque 
des revendications prficSdentes, caracteris€ en ce que 

ladite operation de modification de la base 
20 principale est xine operation logique et que 

ladite operation d'ajout dans la base de 
donnees d'historisation consists H ajouter : 

un enregistrement identifiant I'^tat de la base 
correspondant Si 1' operation logique, 
25 autant d' enregistrements que de paramStres de 

1' operation logique, 

un enregistrement pour le rgsultat Sventuel de 
1' operation logique 

et S prSciser par un lien de parents les 
30 regroupements d' operations depuis le niveau SlSmentaire de 
modification jusqu'au niveau de la transaction, en passant 
le nombre de niveaux s6mantic[ues nScessaires pour les 
applications . 
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4. Proc6d6 d' organisation d'une base de donnSes 
numfirique sous une forme tradable selon I'une quelconque 
des reveadications pr6c6dentes, caract6r±s6 en ce que la 
base de donnges principals contient une ou plusieurs 
table{s), organisant les liens d'Svolution entre les 
identif iants des fitats successlfs et altematifs de la base 
princlpale, destin4e(s) a organiser les enregistrements de 
la base de donnfies interne. 

5. Proc6d6 d' organisation d'une base de donnSes 
numfirique sous une forme tra<?able selon la revendication 4 
caract6ris6 en ce que ladite ou lesdites tables des lienl 
d' Evolution eatre les Stats de la base principale 
coatieaaeat des earegistremeats sp6cifiant les rdgles de 
correspoadance eatre les enregistrements de la base de 
donates iaterae d'historisation et les Stats de la base de 
donnSes principale - 

6. ProcSdfi d' organisation d'une base de donnSes 
numSrique sous une forme tradable selon I'une des 
reveadicatioas 4^5, caractSrisS en ce que ladite 
operation de lecture coasiste 4 determiner ledit Stat de la 
base de doaaSes priaclpale ea se rSfSrant aux dits 
ideatifiaats et aux tables des lieas d'Svolutloa eatre les 
25 Stats de la base priacipale. 

7. Architecture de gestioa de base de donnSes 
utilisaat le procSdS d' iaterrogatioa de I'une quelconque 
des reveadicatioas prScSdeates, caractSrisSe en ce qu'une 
30 application iaterrogeaat la base de donnSee principale peut 
spScifier I'Stat de la base de donnSes priacipale dSsire. 

8. Architecture de gestion de base de donnSes 
selon la reveadicatioa 7, caracterisSe ea ce que ladite 



20 



WO2004/02S507 ^ ^ PCT/FiUM3AM2«75 

application peut opSrer des modifications sxir tout Stat de 
la base principale et donnant lieu, dans le cas de la 
tentative de modification d'un 6tat antgrieur, a la 
creation de nouvelles alternatives d' Evolution de la base 
de donnSes principale dont les donnSes seront gSngrSes par 
la mSme base d'historisation interne. 
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9. Procgdfi d' organisation d'line base de donnges 
num^rique sous une forme tradable selon I'une quelconque 
des revendications 3^6, caractSris6 en ce que les liens 
de dfipendances servent de critSres de remise en cause, 
desdites operations dfija effectu6es. 

10. Proc6d€ d' organisation d'une base de 
donnges numfirique sous une forme tradable selon I'une 
quelconque des revendications 3 a 6, caractSrisg en ce que 
les mises d jour effectuges sur des branches diff^rentes 
pourront fit re intSgrfies ou fusionn^es dans le cadre d'un 
nouvel 6tat « hSritant » desdites branches. 



11. ProcgdS d' organisation d'une base de 
donnfies numSrique sous une forme tradable selon I'une 
quelconque des revendications 3^6, caractSrisS en ce que 
les cas d' Evolution de structure des donn§es de la base de 
25 donn«es principale sont traitfis ccmme des cas particuliers 
d' Evolution des donn^es de ladite base, pour peu que la 
structure/sch§ma de ladite base principale soit decrite de 
la fa<?on mentionnge pour les donn^es, en tant que 
dictionnaire . 



12. ProcSdfi d' organisation d'une base de 
donnSes numSrique sous une forme tradable selon I'une 
quelconque des revendications 3^6, caracterisg en ce que 
la base de donnfies d'historisation est explorSe et 
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iaterrogge par des applications a travere le mode natif du 
SGBD afin d'obtenir des informations comme par exemple 
toutea les valeurs historiques d'un attribut et toutes les 
incidences (dynamiques) de toute mise a jour et de naviguer 
au long des versions et des flux de dgpendance dynamique et 
ceci de facon classique, aelon le langage d' interrogation 
en vigueur, exigg par le SGBD. 
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